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Abstract We report on a transformation from Sequential Function Charts of the IEC 
61131-3 standard to BIP. Our presentation features a description of formal syntax and 
semantics representation of the involved languages and transformation rules. Further- 



more, we present a formalism for describing invariants of IEC 61131-3 systems and 
establish a notion of invariant preservation between the two languages. For a subset of 
our transformation rules we sketch a proof showing invariant preservation during the 
transformation of IEC 61131-3 to BIP and vice versa. 

0^ This work has been supported in part by the European research project ACROSS under the Grant 

r/j Agreement ARTEMIS-2009-1-100208. 

y—{ 1 Introduction 

> 

In this paper we provide a formal definition of a subset of the Sequential Function Chart 
(SFC) language from the IEC 61131-3 standard and the bip language. The IEC 61131-3 
standard |19| describes languages widely used in the industrial control domain to write 
programs for programmable logic controllers (PLC). BIP [2] is a language to describe 
component based systems. It is based on state transitions that are encapsulated into 
components. These components are connected with each other. Via connectors they can 
interact and synchronize. 

We contribute a transformation specification from SFCs into BIP. This transformation 
is designed to preserve the behavior of SFCs while using as much of bips parallelism as 
possible. 

We also present a description for invariants in the SFC language and show how in- 
variants from BIP can be transformed into SFC invariants and vice versa. A proof that 
invariant properties discovered on bip do also hold for the original SFCs is provided to 
show that the transformations are correct. 
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1.1 Related Approaches 

Formal specification and correctness of model to model transformations have been ex- 
tensively studied in the context of graph-transformations [13J. Our work, however, has 
been stronger influenced by approaches to guarantee the correctness or distinct proper- 
ties of compiler runs (e.g., \18 \ I15 | [TTj ) . Our transformation rules for the IEC 61131-3 
to BIP transformation can be regarded as the definition for a compiler. Guaranteeing 
correctness of our transformation by using translation validation like techniques is a long 
term goal of our work. This could be similar to [5] . 

The issue of property preservation has been studied in [16]: The work comprises 
conditions and a proof that under these conditions abstractions preserve temporal logics 
properties. Our transformations may be regarded as abstractions. The invariant based 
safety properties studied in this paper are a simple (but yet powerful) case of these 
properties. 

Various other BIP transformations exist that are relevant for our work. Most notably 
synchronous BIP |llj is a language subset of BIP that is especially suitable for the trans- 
formation of synchronous languages into BIP. The languages of IEC 61131-3 are also 
synchronous. Furthermore the translation from AADL to BIP has been studied [12J. Coq 
certificates guaranteeing correct invariants for BIP have been studied in [8]. 

1.2 Lifting Safety Properties Through a Transformation Chain 

On a general level we are interested in transformation chains where models get trans- 
formed into other models and finally into machine code. Some analysis tool might be 
invoked on one of these representations. In particular we are interested in analyses that 
discover system invariants on one of the intermediate models. Safety results may be 
derived from the analysis of such an invariant. 

We are interested in lifting such invariants and connected safety results from one 
representation to another. In particular we are interested in two different use-cases. 

Use-Case 1: Lifting Invariants and Safety Properties to an Earlier Stage in the 
Model Transformation Chain This comprises the lifting of invariants and connected 
safety properties to the beginning of a chain of model to model transformations (cf. 
Figure [I]), i.e., transforming model' to model and then invariant' to invariant. This can 
be done if the following conditions are fulfilled: 

• Models at an earlier stage in the transformation chain allow at least as much 
behavior as models at the analysis stage in the transformation chain. 

• Invariants at the analysis stage are at most as strong as corresponding invariants 
at earlier stages in the transformation chain. 

The fact that invariants may only get stronger when transforming them for an earlier 
model representation ensures the preservation of safety properties. However, we have to 
show invariant preservation: 
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Figure 1: Use-Case 1 



• We have to show that for each concrete transformation invariant is indeed an in- 
variant of model. 

Correctness of model and invariant transformation can be formally stated in the following 
way. Given a (model to model) transformation function T5 and an invariant transforma- 
tion function Tj: for every system model there is a transformation model' = T5(model), if 
we have discovered an invariant invariant' for model' (denoted model' |= invariant') then 
there exists an invariant invariant = Tj (invariant') such that model |= invariant. If Tj 
preserves safety properties, this ensures that safety properties discovered by analyzing 
I2 do also hold for the original system model. 



Use-Case 2: Lifting Invariants and Safety Properties to a Later Stage in the Model 
Transformation Chain In the second use-case (cf. Figure [2]) we start with an invariant 
invariant and connected safety properties and a model model. All we have to ensure 
to guarantee the soundness (i.e., safety property preservation) of the approach are the 
following two items: 

• Models at an earlier stage in the transformation chain allow at most as much 
behavior as models at a later stage in the transformation chain. 

• Invariants at an earlier stage are at least as strong as corresponding invariants at 
later stages in the transformation chain. 

In this paper we are regarding transformations from the IEC 61131-3 language to BIP. 
Invariant-based static analysis tools like D-Finder that work on bip may be used to 
discover safety properties like deadlock-freedom. These properties are also valid for the 
original IEC 61131-3 model if the sketched conditions (first use-case) are fulfilled. Thus, 
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Figure 2: Use-Case 2 

if we have a trustable code-generation from IEC 61131-3 models and do trust D-Finder, 
we can use this code generation to generate code that we can trust to be deadlock- 
free given a successful D-Finder run. The other application corresponds to the second 
use-case: Lifting safety properties and connected invariants from IEC 61131-3 to BIP. 

1.3 Overview 

We define a formal semantics of the Sequential Flow Chart part of the IEC 61131-3 
standard in Section [2} A summary of the BIP language and its semantics is given in 
Section [3} The transformation from this language into bip is described in Section |4| 
Invariant preservation from bip back to the SFC language is discussed in Section [5] 
The other direction: invariant preservation from SFCs to BIP is presented in Section [6j 
Finally, Section [7] features a conclusion. 

2 The SFC Language and a Formal Definition of its Semantics 

This section presents an overview on the Sequential Function Charts (SFC) language 
and a formal definition of SFC including the operational semantics. This formulation is 
based on the IEC 61131-3 standard [H] and existing work (3j|9j[IU]. We are particularly 
interested in the subset of IEC 61131-3 that is used in the EasyLab toolkit [2]. 

2.1 A Formal Definition of the SFC Syntax 

SFC is one of the graphical programming languages described in the IEC 61131-3 stan- 
dard. It comprises control locations of the system (called steps) and the transition of 
control between them. The passing of control can be restricted via guards. Behaviors 
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of the program is described in action blocks which can be associated with steps. In the 
following, we first define the basic component of SFCs and then describe the composi- 
tion of them. We define in fact two formal descriptions of the SFC language. One that 
supports the subset used by the Easylab toolkit and an extended version that supports 
more features described in the standard. 

Variables in the SFC Language SFCs have variables that are visible to all their com- 
ponents, such as steps, guards and actions. We use X = {x±,X2, x n } to denote the set 
of variables. The current values of X are described using a variable valuation function 
(usually denoted / in the context of this paper) of type X — > valx, which assigns a 
value compatible to the respective data type (valx) to each variable in X. We use T to 
denote the set of all valuation functions of X. 

Action Blocks and Steps (Extended) action blocks and steps in SFCs are the basic 
units for describing the behavior. 

Definition 1 (Actions) An action is an update function of type T — ^ T . 

The definition of actions is the same for extended and non-extended SFCs. 

Definition 2 ((Extended) Action block) For a given set of actions A an extended 
action block is a tuple (a,q), where 

- a is the action, which can be either an update function of type T — > T G A or an 
identifier to a nested SFC, and 

- q is a qualifier q G {N, S, R, Pq, P{\, the semantics of which are introduced shortly. 

A non-extended action block comprises just an update function of type T — > T . In 
this case, the term action block and update function may be used synonymously. 

The same action can be used in multiple action blocks associated with different SFC 
steps. In IEC 61131-3 the update functions can be written in any other languages defined 
in the standard, such as Function Block Diagram (FBD), Structured Text (ST), Ladder 
Diagram (LD) and Instruction List (IL). Here we abstract from a concrete language and 
use mathematical functions instead. 

The action block qualifiers describe the activity of actions. The semantics of the 
qualifiers are defined as follows: 

• N (non-stored) qualifier describe actions that are active only when parent steps 
are activated, 

• S (stored) qualifier describe actions that continue being active until a reset action 
is executed, 

• R (stored) actions are used for reseting active actions, 

• Pq (pulse at falling edge) actions are active only when the parent step is exited, 
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• Pi (pulse at rising edge) actions are active only when the parent step are entered. 
The reset actions tagged with R have always the highest priority. 

Definition 3 (Step) For a given set of action blocks B and its associated set of actions 
A. A step of an SFC is a pair s = (n, CI), where n is a unique identifer for the step and 
fl = 2 B (note that B = A for the non-extended case) is a set of action blocks belonging 
to the step. We use s.fl to refer to the set of action blocks associated with step s. 

The steps can be in inactive, ready or active state. An inactive step does not activate 
any actions. The ready steps are the ones that control resides in. However, it is not 
necessary that the actions of ready steps will be performed. A special situation is in 
nested SFCs, where a step in a nested SFC is ready but the parent action is not active. 
In this case, the actions of ready steps will not be performed. The active steps are those 
ready steps whose actions will actually be performed. 

Guards and Transitions Steps in SFCs are connected via transitions. Transitions fea- 
ture a guard expression. 

Definition 4 (Guard) A guard g is a predicate over a valuation function. It has the 
type g : F — >■ bool, where F is the set of all valuation functions. It evaluates to true if 
the current values of X satisfy g. 

Definition 5 (Transition) A transition t £ T = (t src ,t g ,tt g t) describes the moving of 
control from source steps t src to target steps tt g t- A transition is enabled if the guard t g 
evaluates to true. A transition is taken if no conflicting transition with higher priority 
is enabled. 

SFC Definition The definition of SFCs is the same for both extended and non-extended 
SFCs. However, the set of actions has a different type. 

Definition 6 (SFC) An SFC is a 7-tuple S = (X, A, S, S , T, C, -<), where 

• X is a finite set of variables, 

• A a finite set of actions, 

• S is a finite set of steps, comprising action blocks which depend on A (in case of 
non-extended SFCs are equal to A) 

• So is the set of initial steps, 

• T C (2 5 \{0}) xGx (2 S \{$}) is the set of transitions, where G is the set of guards, 

• n<E A x A is a total order on actions used to define the order in which the active 
actions are to be executed, and 

• -< € T x T is a partial order on transitions to determine the priority on conflicting 
transitions. 
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Figure 3: An example SFC 

Example Figure [3] depicts an example non-extended SFC model consisting of four steps 
and three actions. Its formal definition is: 

■S = {{x,y}, 

{51,52,53,54}, 
{al, a2, a3}, 
{SI}, 

{ ({SI}, xl < 10, {S2}), ({SI}, x > 10, {S3}), ({S2},x > 15, {54}), 

({S3}, x<5, {54}), ({54}, true, {51}), }, 
{al Ca2c a3}, 
{tl -< t2}, 

} 

2.2 Operational Semantics of SFCs 

As proposed in [3], the operational semantics for SFCs is based on configurations de- 
scribing the system state Q 

Definition 7 ((extended) Configuration) An extended configuration of an SFC and 
its sub-SFCs is a 5-tuple c = (f, ready S, activeS, activeA, storedA), where f is the func- 
tion describing the current values of variables. The rest are four sets describing the states 
of steps and actions. In particular, ready S is the set of ready steps, activeS is the set of 
active steps, activeA is the set of active actions and storedA is the set of stored actions. 
Non extended configurations have the following form: (f, activeS, activeA) . 



1 In this paper, we use the term system state and configuration interchangeably 
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Semantics of Extended SFCs Execution of one SFC-cycle consists of the following 
three phases: 

• Phase 1: execute actions contained in set active A and update the values of variables 
correspondingly; 

• Phase 2: perform step transitions and update the sets readyS, activeS; 

• Phase 3: compute the set of active/stored actions activeA and storedA for the 
next cycle. 

In each of the three phase, the configuration of the SFC system is updated. The 
semantics of an SFC can then be regarded as a transition system of the configurations. 

Definition 8 (Transition system of an extended SFC) An extended SFC 

S = (X,A,S,S ,T,r,^) 

is associated with a transition system £(S) = (C,cq,— >), where C is the set of configura- 
tions, Co is the initial configuration and ->CCxC is the transition relation. 

Elements in the transition relation for extended SFCs have the following form: 

(/, readyS, activeS, activeA, storedA) — > (/', ready S' , activeS' , activeA' , storedA') 

The details of the transition relation are described as follows: 

• In Phase 1, /'is updated by performing the set of active actions, which are executed 
according to the orders specified in C, that is, /' = (a m o ... o a±)(f), where 
a\ C ... C a m and {a±, ...,a m } are the set of active update functions. The rest of 
the configuration remains unmodified. 

• In Phase 2, readyS, activeS are updated and the rest of the configuration remains 
the same. readyS' is obtained by evaluating transitions T. Let c be the current 
configuration, the set of transitions that can be taken can be identified as T = 
{t = (t src ,t g ,ttgt) 6 T | t src C activeS A c |= t g A (-3t' . t' src C activeS A c |= 
g' A t src n t' src ^ At -< t')}, that is, a transition is taken if its guard is satisfied and 
the conflicting transitions, which are transitions originated from the same step, are 
either not enabled or of lower priority. Then, the active steps for the next cycle 
can be obtained as readyS' = ready S\{t src \t £ T} U {tt g t\t € T}. Since actions 
can be associated with multiple steps, it is also possible that actions get activated 
multiple times with different qualifiers. Hence, to decide if a step or action is in 
active state, we need to inspect all its activations. For that, the iterative methods 
proposed in [3] can be used. From the top level SFC, the algorithm iterates over 
all nested SFCs to find all active steps (activeS'). 

• In Phase 3, activeA and storedA are updated and the rest of the configuration 
remains the same. The iterative algorithm in [3] finds beside activeS' also the set 
of all qualifiers that appear in activations of each action. We use a(a) to denote 
this set of qualifiers for action a. Then: 

- activeA' = {a G A \ a(a) n {N, P , P x } ^ A R $ a(a)} 

- storedA' = {a £ A \ S £ a(a) A R <£ a(a)} 
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Semantics of Non-extended SFCs The focus of this paper is to investigate invari- 
ant preservation properties for a subset of SFCs supported by EasyLab (non-extended 
SFCs), in which the following restrictions are added: 

- the nested SFCs are not allowed; 

- only N qualifier is supported. 

With these restriction, the configurations can be simplified by eliminating the sets 
readyS and storedA, because readyS = activeS always holds and storedA is always 
empty. The case of the entire SFC language will be addressed in future work. 

Definition 9 (Transition Systems of non-extended SFCs) An non-extended SFC 
is also represented as a tuple S = (X, A, S, So, T, -<). Due to the simplification, the 
transition relation has the form: 

(f, activeS, activeA) — > (/' , activeS' ', active A') 

For non-extended SFCs, a simplified version of operational semantics can be defined 
and the set of reachable configurations can be regarded. Let [S'Mjs'pc denote the set 
of all possible configuration transitions of a non-extended SFC SM. It can be formally 
defined as follows: 

(c,c) = ((/ ', activeS, activeA), (/' ,activeS' , active A')) G [S'Mj^^c* 

*// 

executeAction(c, c) V stepTransition(c, c) V activateAction(c, c) 

The term execute Action, stepTransition and activateAction represent the three possi- 
ble types of configuration transitions. Formally, 

executeAction(c, c) =3 a £ activeA . f = d(f) 

A activeS = activeS' A activeA' = activeA\{a} 
stepTransition(c, c') =3 t G T . t src C activeS A t g (f) A / = /' 

A (activeS' = activeS \ t src U t tg t) A activeA = activeA' 
activate Actionize, c) =3 s G activeS.3a ^ activeA.a £ s.Q 

A / = /' A activeS = activeS' A activeA' = activeA U {a} 

The reachable configurations of SM can then be inductively defined as follows, de- 
manding that the initial state is reachable and each reachable configuration must be able 
to be reached from it via valid transitions. 

ReachableConfigsFc(c) = 
c = c 

V 3d .ReachableConfigsFc(c') A (c',c) G ISM} S FC 
The elements in [[S'M^^c are the basic configuration transition steps of SM. For 
the rest of the paper, we introduce the notation (c -^>s_fc c'), which means (c, c') G 



J smallest fixpoint 
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{SMJsfc, i-e., d can be reached from c via a single transition step contained in \SM\sfc- 

SM 

Another notation (c — >sfc c ') means d can be reached from c via multiple of the tran- 
sition steps contained in \SM\sfc- 

3 BIP and its Semantics 

In this section we present a subset of the bip language, bip allows the modeling of 
asynchronous components and of interactions between them. We discuss its semantics 
and an example bip model. Parts of this section follow the presentation given in [7] 
building upon [3J. 

3.1 BIP models 

BIP (Behavior, Interaction, Priority) is a software framework designed for building em- 
bedded systems consisting of asynchronously interacting components, each specified as 
a non-deterministic state transition system. Tools developed for bip comprise static 
analyzers and code generation. 

Atomic Components bip models are composed of atomic components [3J|5]. An atomic 
component (L, P, T, V, D) is a state transition system consisting of a set of locations L, 
a set of ports P, a set of transitions T, and a set of variables V which are mapped to 
values of type D. An atomic component has a distinct state of type 

L x (V -»■ D) 

comprising a location and a variable valuation. The latter is a mapping from variables 
to their values. Transitions are of type 

T C L x {{V -> D) -> bool) x ((V -> D) -> (V -> D)) x P x L 

They comprise a source location, a guard function, an update function, a port, and a 
target location. Our semantics requires that a transition from one location to another 
can be performed iff the guard function evaluates to true using the variable valuation in 
the current state. During a transition the variable valuation is updated for the succeeding 
state. Furthermore, it is possible to restrict transitions by putting constraints on the 
port involved in the interaction. 

Each port pGP can have an associated variable. This variable is used to exchange 
data between different atomic components in composed components (see below). The 
functions V(p) : P — > V U {e} defines the association between port and variable. If the 
result of V is e, the port does not exchange data. 

Figure [4] shows an atomic component comprising two locations (I5 and Iq), and a vari- 
able 9 that has a numeric value. Four possible transitions exist between these locations 
which are depicted as arcs. Each one comprises a port (tick, cool, heat), a guard which 
checks for conditions of the variable 9, and an update functions which is empty on two 
arcs ( ) and modifies the value of the variable 9 on the other arcs. 
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Figure 4: An Atomic Component 

Composed Components Atomic components may be glued together to form composed 
components. The behavior of the resulting system can be restricted by linking compo- 
nents with connectors. These put constraints on ports in the different atomic compo- 
nents. A composed component is a tuple (A, C) comprising a set of atomic components 
A and a set of connectors C. 

C C (A x P) x 2 AxP 

Connectors have the following form: ((a Sl p s ), (02,^2), (a n , P n )}) comprising 

an atomic component a x G A; x G {s, l...n} and a relevant port p x G P 0a . with P ax being 
the set of ports associated with a x . If the connector is used to exchange data, the data 
is copied from a s to all af,i £ l...n. For connectors without data exchange there is no 
difference for a s and a^. 

In an extended version the connectors may contain guard functions, depending on the 
variable valuations of the linked components, and update functions which are performed 
on these variable valuations and mechanisms for value exchange between components. 

Gluing components together by using connectors realizes weak and strong synchro- 
nizations as well as broadcasts between components. Update functions on the involved 
variable valuations are used to pass values between components. 

Semantics of Composed Components The state of a composed component is the 
product of its atomic components' states: (L\ x {V\ — > D\)) x . . . x (L m x (V m — > D m )). 
A state transition relation [[SMj^/p is defined upon them for a composed component 
BM = (A, C). We assume an indexing of atomic components A = {ai, ...,a m } 

(((Zi,a;i),...,(Z m ,x ro )) , G {BM\ B ip 



11 



iff 



3(c s ,C r ) G C : Vi G {l...m} : 
(3j G {l...m} : 

(3p : (o 3 -,p) = (7s A V(p) = Uj) 
A V(pi) = Vi 
A (k,9i,fi,Pi,li) G Oj.T 

Ax'i = fi(xi)[vi «- 
A(ai,Pi) G ({c s }UC r ))V 
& = ^ 

A--(3p: (oi,p) G ({c s }UC r )) 
A Xi = x'i) 

di.T denotes the set of transitions associated with component aj 

Reachable States of BIP models The set of reachable states for a bip model BM for 
a given initial state sq is defined by a predicate Rbm via the following inductive rules: 

Rbm{s) (s,s r ) €lBMj BIP 

Rbm(sq) Rbm(s ) 

The first rule says that the initial state is reachable. The second inference rule captures 
the transition behavior of BIP using the transition relation. 

3.2 An Example 

Figure [5] shows a temperature control system modeled in BIP, which has been well dis- 
cussed in the literature (e.g., JSJUJE]). ^ uses ^ ne component from Figure [4] but puts 
constraints on the ports in order to use it as a controller. 

The system controls the cooling of a reactor by moving two independent control rods. 
Each one has its own timer t\, ti- After the usage of a rod there is a timeout t max until 
it can be reused again. The goal is to keep the temperature 6 between 9 m i n and 6 max - 
When the temperature reaches the maximum value, one of the rods has to be used for 
cooling. The bip model comprises three atomic components: one for each rod and one 
for the controller. Each contains a state transition system. Transitions can be labeled 
with guard conditions, valuation function updates, and a port. The components interact 
via ports thereby realizing cooling, heating, and time elapsing interactions. In the figure, 
possible interactions are indicated by arcs connecting ports from different components. 
These require that either in every connected component a transition labeled with the 
connected port must be taken in parallel or none of these transitions is taken. For 
example, the time elapsing tick transitions must be taken in each component in the 
same parallel step (tickl , tick, and tick2). Depending on the values of 9 max , 9 m i n , and 
tmax the system might either contain a deadlock or not. 
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Figure 5: Temperature Control System 



Let us introduce two invariants for the example model with 9 max = 1000, 9 m i n = 100, 
and t max = 3600: 

1. h = (ati 5 A 100 < 9 < 1000) V (at k A 100 < 9 < 1000) 

This invariant states that the temperature will always be between 100 and 1000. 

2. I 2 = (at h A h = 0) V (at h At 2 = 0)V (at k A 101 < 9 < 1000)V 
(at k A {9 = 1000 V 100 < 9 < 998)) 

This invariant states that the timer in one of the rods is zero or we are in the 
heating phase and the temperature is already above 100 or we are in the cooling 
phase and the temperature is 1000 or between 100 and 998. 

aU is a predicate denoting the fact that we are at location i in a component. The first 
invariant is restricted to a single component, the second one combines facts about several 
components. 



4 Transformation from SFCs to BIP 

This sections describes the transformation rules from the SFC language to BIP. 

For a given SFC S = (X, A, S, So,T,\Z, -<, h), the transformed bip model can be 
represented by a composed component B = (A, C), with A C Lx P xT xV x D being the 
set of atomic components and C C (AxP)x 2 AxP the set of connectors. In the following 



sections, we first describes the atomic components including their formal definition (4.1 ), 



and afterward the transformations steps and connections of atomic components (4.2). 



SFC evaluation phases As introduced in Section 2.2 , execution of an SFC is done in 
SFC cycles, which consists of three phases: 

1. execution of active actions, 
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2. evaluation of transitions and identification of active steps, 

3. identification of active actions for the next cycle. 

In the generated BIP model, an SFCManager component is introduced to enforce syn- 
chronization of the phases. This is done with the wTick (work tick), tTick (transition 
tick) and /Tick (finish tick) signals. 

4.1 Atomic Components 

Several transformation templates can be identified for the transformation of SFC ele- 
ments into bip elements. 

Actions Each SFC action a 6 A will be represented by a bip component d £ A. Each 
action has two ports for synchronization with the BIP representation of the SFC program. 
The work port starts the action. Then it reads all input data, processes the data and 
writes the output value. At last is enables the done port to signal its ACB (see next 
paragraph) that it has finished processing. 

To access global variables, the action has a read x and/or a write x for each variable 
x is accesses. They are connected to the read and write ports of the global variable 
atomics. 

Action Control Blocks For an action component a £ A transformed from an SFC ac- 
tion a £ A, a special atomic component called Action Control Block (ACB) is equipped, 
which is responsible for collect and evaluate qualifiers from action activations to decide 
if the action will be executed for the next SFC cycle. We use b a to denote the ACB 
component created for d and B for the set of ACB components for all actions. 

Transformation 1 (Action Control Block) 

CreateACB(a) : A^LxPxTxLxVxD 
CreateACB(a) = (L A cb, Pacb,Tacb, L 0acb ,Vacb, Dacb) 
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with the following substitutions: 

L ACB = {ACTIVE a , WORK a , WORKED a , WAIT a } 
Pace = {wTick a , tTick a , N a , S a , R a , work a , done a } 
Tacb = { 

{ACTIVE a , true, {}, tTick a , WAIT a ), 

(WAIT a , true, {e <- (-r A (s V n)); s <— (pr As);r(-0;nf- 0}, 

wTicka, ACTIVEa), 
(ACTIVEa, e, {}, work a , WORK a ), 
(WORKa, true, {},done a , WORKED a ), 
(WORKEDa, true, {},tTick a , WAIT a ), 
(WAIT a ,true, {n <- 1}, N a ; WAIT a ), 
(WAITa, true, {r <- 1}, i? a ; WMJT a ), 
(WM/T a ,true,{s <- 1}, S a ; WM/T a ), 
} 

L 0acb = {WAITa} 

Vacb = {n a : 600/ , s a : bool, r a ■ bool, e a : bool] 
D ACB = {0, 1} 



A graphical representation can be found in Figure |6| Each ACB contains a set of 
boolean variables r, n and s, which are set to true if the respective qualifiers R, N and S 
appeared in the previous SFC cycle. At the end of the previous SFC cycle, the collected 
qualifiers are evaluated to determine if the action will be executed (by computing e) and 
if it will be stored (by computing s). In the beginning of the current SFC cycle, the 
ACB is triggered to ACTIVE by wTick signal. Then, the associated action is executed 
by sending the work signal if the boolean variable e computed from the previous cycle 
is true. When the execution of all actions finishes, the SFC manager triggers all ACBs 
to the WAIT location by tTick signal, in which action activations for next SFC cycle 
are collected. The fTick signal triggers the ACBs to back IDLE locations at the end 
of current SFC cycle. 

For non-extended SFCs, the ACB component can be simplified. Unused variables r, s 
and n can be eliminated and gathering of quantifiers can be modeled as a simple location 
transition. Figure [7] is such a simplified guard component. 

Steps A step in SFC s £ S is represented by an Atomic BIP Component s £ S defined 
as follows. 

Transformation 2 (Step) 

CreateStep(s) : S^LxPxTxLxVxD 
CreateStep(s) = (L step, Pste P ,T step ,L 0step , {},{}) 
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Figure 6: bip Atomic Component for an Action Control Block 




Figure 7: bip Atomic Component for an Action Control Block for Non-extended SFCs 



16 








tin 






flick , 






flick 


((DISABLED)) 




tOiitf tJnlact 


act 


Qactivej) 


(^ACTION?} 






fTick 






tOut 





(a) SFC (b) bip 

Figure 8: Transformation of an SFC Step into bip 



with the following substitutions: 



L 



Step 



{DISABLED s ,ACTIVE s ,ACTION s } 
Pstep = {tIn s ,tOut s , f Tick s , act s } 
Tstep = { 

(ACT IV E s , true, {}, tOut s , DISABLED S ), 
(DISABLED s ,true, {},tln s , ACTIVE S ), 
(DISABLED s ,true, {}, fTick s , DISABLED S ), 
(ACT IV E s , true, {}, fTick s , ACTION s ), 
(ACTIONs, true, {},act s , ACTIVE S ), 
} 

L 0step = {DISABLEDs} 



A graphical representation can be found in Figure 8b 

The tin and tOut Ports are used to enable and disable the steps; fTick is used for 
synchronization within the SFC evaluation phases. The act port is used to activate 
actions. 

After the tTick has been sent by the SFC manager, the step transition guards (in- 
troduced later) will evaluate all transition conditions. For an enabled transition, the 
BIP components representing the set of source steps will be forced from ACTIVE to 
DISABLED by receiving the tOut signal from the guard. Similarly, the set of bip 
components representing the target steps are triggered to ACTIVE location. Further 
on, on receiving the fTick, activation signals are sent to ACBs of actions associated 
with active steps. 

Guard For each step transition t = (t src ,t g ,tt g t) € T in SFC, a guard t g is associated. 
This guard is built as an atomic component t g £ Aq in the BIP domain. The definition 
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of the guard atomic component is as follows: 
Transformation 3 (Guard) 

CreateGuard(t) :T->LxPxTxLxVxD 
CreateGuard(t) = (L Guard , Pcuard, T Guard , L 0Guard , {}, {}) 

with the following substitutions: 

L G uard = {WAIT t , READ t , GUARD t , ACT t , DONE t } 
Pcuard = {val t , guardt, tTick t , fTick t , act t } 

T^Guard — { 

{WAITt, true, {}, tTickt, READt), 
{READ t , true, {},val t , GUARD t ), 
{GUARD t ,true, {}, fTickt, WAIT t ), 
{GUARD t , g, {},guard t , ACT t ), 
{ACT t , g,{], act t , DONE t ), 
{DONEt, true, {}, fTickt, WAIT t ) 
} 

Lo Guard = {WAIT} 



The most important part of the guard is g, which represents the condition for this guard. 
Because the conditions may differ, a BIP guard component has to be customized for each 
SFC guard. Also, access to variables has to be added. The sample in Transformation [3] 
just reads one variable vol. Figure 9b contains a graphical representation of the sample 
guard. 

In WAIT location the guard is waiting for begin of the second phase (port tTick), 
in which it first reads the global variables that are necessary to evaluate g. Then, if 
the condition g evaluates to true, the guard port is activated. If the transition the 
guard is connected to can be taken, the guard component moves to ACT. The guard 
port is connected to the tln/tOut Ports of the bip components that represent predeces- 
sor/successor SFC steps. The location ACT is introduced to activate actions with PO 
and PI qualifiers, respectively. The activation ports are connected to the N ports of the 
associated actions. Note that for both PO and PI activations, the activation ports of a 
guard send actually a N activation. This is because the behavior of P0/P1 activation 
is the same as that of iV activations, except that P0/P1 activations are only enabled 
during step transitions. The second phase of an SFC cycle is finished with fTick. In 
Figure 9b a graphical representation of a guard component is presented. 

For non-extended SFCs, the qualifier PO and PI is not used and associated activation 
port can be eliminated. Figure 10 shows a bip guard component for non-extended SFCs. 
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gure 10: The BIP Guard Component for non-extended SFC 
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SFC Manager The SFC Manager component, displayed in Figure 11, enforces the 
synchronization of the SFC execution phases by periodically enabling its wTick, tTick 
and /Tick ports: 



Transformation 4 (SFC Manager) 

rh = (L A /, Pm,T m , L 0m , {}, {}) 
L M = {WORK m , TRAN m , DONE m } 
P M = {wTick m ,tTick m , fTickm} 
T M = { 

(WORK m , true, {} ,tTick m ,TRAN m ), 
{TRAN m ,true, {}, fTick m , DONE m ), 
(DONE m , true, {},wTick m , WORK m ) 

} 

L 0m = {DONE m } 

Synchronization is done by connecting all wTick, tTick, fTick ports of all components 
that need the signal. 
The three phases are: 

• WORK: This phase is started by the wTick. During this phase all enabled actions 
are executed by their action control blocks. During this phase the actions read 
global variables (including input data), process them and write the results back. 
The results don't get valid in this phase. 

• TRAN: This phase starts with the tTick. With the tTick the results of the actions 
get valid. Afterwards the conditions of the guards are evaluated and, if possible, 
taken. SFC Actions that are called with the PO or PI action qualifiers are marked 
in their ACB during this phase. 

• DONE: The third phase is initiated by the fTick, after all possible transitions have 
been taken. In this phase all actions that should be executed in the next round are 
determined by evaluating the action qualifiers. The ACB stores this information. 

Variables The bip language does not support global variables that are accessible to all 
components. Hence, an SFC variable x £ X is encapsulated as an atomic BIP component 
Global Variable (GV) defined in the following: 

Transformation 5 (Global Variable) 

CreateGV(x) : X^LxPxTxLxVxD 

CreateGV(x) = (Loiobal, PciobahTciobal, LQ Global ,VGlobah T>Global) 
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Figure 11: SFC Manager 



read write tTick wTick 



write 

{t=write.v;} 




Figure 12: Global Variable 



with the following substitutions: 



^■Global 
PGlobal 
Tciobal 



L G lo, 



Global 



{READ X ,WRITE X } 

{read x , write x , tTick x , fTick x } 

{ 

(READ X , true, {}, read x , READ X ), 
(READ X , true, {t x = write x .v}, write x , READ X 
(READ X , true, {v x = t x }, tTick x , WRITE X ) 
(WRITE x ,true, {},read x , WRITE X ), 
(WRITE X , true, {},wTick x , READ X ) 

} 

{READ X } 



y Global = {tx,V x } 
Daiobal = % 



The GV component contains two variables t and v, both are of the same type as the 
corresponding SFC variable. The variable v hold the actual value of the SFC variable 
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wTick 




tOut 



Figure 13: SFC Starter 



whereas t is a temporary buffer. Initially, the GV component is in READ location, in 
which reading of the variable value is allowed and writing of the variable is buffered 
in t. The buffer value is written to v on receiving the tTick signal, that is, when all 
actions has been performed. This guarantees that all actions read the consistent value 
of v. On the other hand, the buffered value is written immediately with the tTick, so 
that the guard components can read the up-to-date value of variables and evaluate the 
transition conditions correctly. The wTick brings the GV back to WRITE location. 



Figure 12 is the graphical representation of the GV component, in which write.v is the 



value exchanged via the write port. 

Starter This component activates the initial steps of the SFC program: 
Transformation 6 (Starter) 

CreateStarter(r) : S ^TxPxTxTxVxD 
CreateStarter(r) = (T st arter, I 'starter, Tstarter, Lo starter , {}, {}) 

with the following substitutions: 

Tstarter = {DI S AB TE D T , ACT IV E r } 

Pstarter = {tOut T , wTick r } 
^Starter — { 

(ACTIVE r , true, {}, tOut r , DISABTED r ), 
(DISABLED r , true, {},wTick r , DISABTED r 

} 

Lo StartEr = {ACTIVE r } 



Figure 13 contains a graphical representation of the component. The wTick is needed 



to ensure that the initial step is activated before any word is done. 
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Figure 14: Initial Step 
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Figure 15: Use of Global Variable X in F2 
4.2 Transformation Steps 

The following describes the steps necessary to convert an SFC program to a compound 
bip component. All created instances of atomics are added to A. 



For each global variable x € X we create an instance of the bip Global Variable atomic 
component x: 

A x :={x := CreateGV(x)|x G X} 
For each Action a € A create an instance a of it in BIP. 

Aa :={a := CreateAction(a)|a G A} 
For each Action a G A create an instance of ACB component b a in bip and connect the 



work and done ports correspondingly (see Figure 16b). 

A B := <{\ := CreateACB(a)|a G A^ 
Ca ■—{((b a ,work\ ,{(a,work)}^J \a G A A } 
U | (^(b a , done^J , {(a, done)}^j \a G A4 j 
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(b) bip 



Figure 16: Action 



For each SFC Step s G S instantiate the BIP Step component s. 

As :={s := CreateStep(s)|s G S} 
For each initial step s G So create a bip Starter instance r s and create a connector to s 



(Figure 14). 



As -={r s := CreateStarter(s)|s G So} 
Cs :={((t s ,tOut),{(s,tIn)})\t s G A So } 

For each SFC transition (t src , g,td s t) = t G T create a guard component gt in BIP 
and connect it to tOut of i src and tin of it 9 f. If the reading of variables is needed 
for evaluating the condition, necessary read ports, locations and transitions are created 
according to Figure |9] 

Aq :={g t := CreateStarter(i)|t G T} 

C T := |J < [{g u guard), \J {(s,tOut)}U \J {(5, tin)} 

(tsrc,tg,ttgt)=teT [ V S& arc S&tgt 



Connect all actions and guards to global variables if necessary (see Figure 15) 



C x ■= (J {((x, read) , {(a, x r )}) ,((a,x w ) ,{(x, write)})} 

(x,a)^A x xA A 

U |J {((x,read),{(a,x r )})} 

(x,g)eA x xA G 
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(a) SFC (b) bip 

Figure 17: Transition 



For each step s G S create a connector to the ACB b of all actions it activates. Use the 
port of the ACB according to the action qualifier. For the P0/P1 qualifier connect the 
N port of the ACB to the guards act port. 



a > ^ 

(s,act), [j {(&<*,<?)} 



I V 



(a,g)Ss.f2 

9 e{JV,s,P} 

r / 



u u 

{tsrc-fig )ttgt) — t£T 



(g t ,act), (J {(X,iv)}u (J {(ba,iv)} 



(a,Po)es.n 



(a,Pl)es.fi 
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Create an instance of the SFC manager component rh and connect the wTick, tTick 
and /Tick ports to all components that expect these signal. 

C M :={((m,wTick),{(a,wTick)\a G A B UA x uAs })} 
U{((rh,tTick),{(a,tTick)\a G i B U i G U ix})} 
U{((m, f Tick), {(a, fTick)\a ei s U i G })} 

Putting everything together 



A 
C 
B 



=A X ui 4 ui B uisU A So ui G U {m} 
=C X UC A U C So UCtUCbUCm 

=(A,c) 



In the following some samples for the transformation of transition are provided. 
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Figure 18: Divergence 
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(a) SFC 
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Figure 19: Convergence 
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(a) SFC (b) bip 

Figure 20: Parallel Divergence 
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(a) SFC (b) bip 

Figure 21: Parallel Convergence 



tin 



S4 



Guard 



Figure 17 shows a simple transition from one step to the following step. In bip tOut 
of the source step and tin of the destination step are connected together with a guard 
the checks the condition. 

An alternative branch is shown in Figure [l8j Here we have one connector and a 
single guard for each branch in bip. Depending on which guard evaluates true first the 
associated following step is taken. Figure 19 shows the opposite. Two branches are 



united. In bip each branch has one connection to tin of the following step. 



A parallel branch (Figure 20) looks similar to an normal transition, expect that it 



connects one source step with two following steps. It has also just one guard. The merge 



of parallel branches is shown in Figure 21 The connector can only switch, of all source 
steps are active and the guard evaluates to true. 
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5 Invariant Preservation of the SFC to BIP Transformation 



In this section, we formally define and prove our invariant transformation function. 
We consider in this work only the non-extended SFCs. Given such an SFC S = 
(X, A, S, So, T, C, -<) and the transformed BIP model B = T(S), the invariant trans- 
formation function Tj takes an invariant on a BIP model and returns an invariant on an 
SFC model. Our final goal is to prove that B \= I — > S \= Tj(I) holds. By definition, 
an invariant is a predicate on configurations that holds for all reachable configurations. 



The set of reachable configurations of SFC and BIP is defined in Sections 2.2 and 3.1 
respectively. 

The BIP model B = (A,C) transformed from S contains a set of atomic components 
A = A x U A A U A B U A s U A So uA G U {m}. The system state (configuration) of any BIP 
model can be denoted as c = (atl,a), where atl : A — > L is a function that returns the 
current location of each component and a is function that returns the current value of 
variables in each component. The notion var(s) denotes the set of variables of component 
s and s.v denotes the particular variable v of component s. 



General Proof Sketch We divide the proof of invariant preservation for model trans- 
formation into two steps. In the first step, we introduce a relation i?(c, c) between a 
reachable configuration c in the original SFC model and a reachable configuration c in 
the transformed BIP model. Our first proof goal is to show that for each SFC transition 
(c, c') G \_SMJsfC) we can always find the corresponding BIP configuration pair (c, c!) 

such that R(c, c) A R{d , c') A (c — -+bip where c — ^bip & ls t rue if their exists a 
sequence of transitions contained in [SMJ_bjp that transforms c to c'. This property 
guarantees that the behavior in the SFC domain can always be traced in the BIP do- 
main. Our proof goal in the second step is to show that the invariants are preserved for 
two configurations in the relation R. 

Let's first assume that the two proof goals discussed above are true. Consider an 
arbitrary invariant I in BIP and the transformed predicate Tj(I) in SFC domain, we 
want to show that Tj(I) is indeed an invariant of the original SFC model. For that, we 
need to show that Tj(I) holds on each reachable configuration of the SFC. According 
to the first proof goal, for an arbitrary reachable configuration c in an SFC, we can find 
a configuration c in BIP such that R(c, c) holds. Since an invariant must hold for all 
configurations by definition, I must also hold for c. The second proof goal then states 
that the predicate Tj(I) holds for c. Thus, we can conclude that for any invariants in 
BIP, the transformed predicate is an invariant of the corresponding SFC. 
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The relation R can be formally denned as follows: 

Vc = (/, activeS, activeA), Vc = (atl, a), R(c,c) holds iff 
rulei(c, c) A rulei{c, c) A rules(c, c), where 

rulei(c, c) = V s £ S, s £ A s . s G activeS = ->(atl(s) = DISABLE) 
rule2(c, c) = V a £ i,o G ^4a 5 &a G Ab • « G activeA = (a(h a .e) = 1) 
rules(c, c) = Vi£l,i 6 Ax • /(x) = a(x.v) 

The first step of the proof is to shown that both Gl a and Glj, holds: 

Gl a : R(c ,co) 

Gib : Vc, c ,c . c ^^-sfc c' A i?(c, c) 

-»• 3c' . c ^>b/p c A i?(c', c') A BM = T(SM) 

The second step of our proof is to show that for all configuration pairs in the relation, 
the invariant is preserved. Formally, the second proof goal G2 is: 

G2 = Vc, c . R{c, c) -»• (Vf . c |= I -»• c |= T/(J)) 

where 7 is a invariant in BIP model and Tj is the invariant transformation function that 
maps 7 to an invariant in SFC domain. The notion c |= 7 means c satisfies 7. 

Proof of Gl a The proof that Gl a = R(co,cq) holds can be done based on the model 
transformation rules: 



• for each initially active step, a starter component is added in the BIP model, which 
triggers the step component to the ACTIVE location (rule\ fulfilled); 

• no action should be active in cq and the initial value of variable e in the ACB 
blocks are set to false {rule?, fulfilled); 

• the value of variable v of GV components are initialized according to the SFC 
variables (rules fulfilled). 

Based on the above transformation rules, it can be trivially shown that the R(cq,cq) 
holds. 

Proof of Gib For the subgoal Gib, we make a case distinction on three possible types 
of transitions of the SFC. 

1. In an execute Action transition, some action a is executed which updates the value 
of SFC variables. An action can be executed only if it is active, hence, a G 
activeA. In the corresponding BIP model, the SFC manager enforces that all 
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action execution is performed between the /Tick of the previous cycle and the 
tTick of the current cycle. Let a be the action component and b a be the ACB 
component created for a. Since the relation R(c, c) holds, the e variable in b a 
is true according to rule2- From the structure of ACB component (Figure [7]), 
we can see that b a can be on the ENABLE, IDLE or ACTIVE location. In 
all cases, the transition from location ACTIVE to WORK will be taken after 
next wTick signal. This transition triggers the execution of action component a, 
which performs the same set of operations as specified in a, because the model 
transformation just copies those operations. The transition also set the value of 
b a .e to false. Execution sequence of the actions in the BIP model is guaranteed 
to be the same as in original SFC model, since transition from location ACTIVE 
to WORK in each ACB component is prioritized according to the order C Let 
c' be the BIP configuration in which the action a is just done (b a in WORKED 
location). It can be easily seen that rule2 in the definition of relation R holds 
for (d ,c'). On the other hand, since tTick interaction has the lowest priority, no 
tTick is issued during the transition from c to c'. So, no step component goes to 
location DISABLE, which means rule\ holds for (d , c'). In addition, the relation 
R(c, c) says that the current values of variable v in GV components are the same 
as that of SFC variables X. Hence, the input of operations in a is the same as that 
of a. Since component a doesn't contain any internal variables, the output values 
will be the same, thus rules holds for R(c',c'). We can conclude that we reach an 
configuration c' such that R(c',c') holds. 

2. In a stepTransition, the set of active steps is updated by taking some enabled 
transition t and the rest of the configuration is not affected. According to the op- 
erational semantics of SFCs, step transitions are performed after execution of all 
active actions identified from the previous cycle. In the transformed BIP model, 
we achieve this point after the tTick signal. At this moment, all ACB compo- 
nents are in WAIT location and all guard components are ready to read values 
from GV components. Let t g be the guard component created for t. Accord- 
ing to the relation R(c,c), the variable values of GV components are the same 
as SFC variables X. This guarantees that, if t can be taken in the original 
SFC model, the condition g in the t g component must evaluate to true. Dur- 
ing model transformation, the transitions from location ACT to DONE in all 
guard components are assigned to higher priority than fTick, hence, the interac- 
tion ((t g , guard), {(s\,tOut), (s" n , tOut), (s\,tOut), (sm,tOut)}) will be taken 
before next fTick signal, where {si, ...s" n } are BIP atomics created for steps s G t src 
and {si, 4} are the corresponding components for steps s £ t tg t- This inter- 
action triggers all source steps of transition t to DISABLE location and triggers 
all target steps of t to ACTIVE location. It can be easily shown that the rule\ 
of relation R is fulfilled after this interaction. On the other hand, in both SFC 
and BIP model, the set of active actions and the values of variables do not change. 
Thus we reach a configuration c' such that R(c',c') holds. 
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3. The third type of SFC configuration transition is the computation of active actions, 
which is the last phase in an SFC execution cycle. In the transformed BIP model, 
we reach this point after an /Tick interaction. The relation R(c, c) says that for 
each active step in the SFC, the corresponding step component in BIP must not 
in DISABLE location. Hence, before the next wTick, all active steps compo- 
nents will activate the associated actions (Figure [8]) , since wTick interaction has 
the lowest priority. According to the model transformation rules, for each action 
contained in the set 0, a connector is constructed that connects the activation port 
of the step component with the ACB component. Thus, the set of active actions 
will be the same in both SFC and BIP models, given the set of active steps are the 
same. This guaranteed that rule2 holds. Since the rest part of the configuration 
doesn't change in both models, we reach a configuration c' such that R(c' , c') holds. 

As shown above, for all types of configuration transitions in SFC, the proof goal Gib 
holds. Note that we made the implicit assumption in our proof that we either use the 
same datatypes for both SFC and BIP model or no overflows and underflows of value 
ranges occur. 

Before we present a proof of G2, a formalism for describing the invariants in SFCs 
and BIP models is needed, which is presented in the following paragraphs. 

Invariants on SFC The syntax of an SFC invariant can be expressed as follows: 



/ : 


:= i A i 


i : 


■i 

:= i 


*': 


:= i' V »' 


i' : 


:=*" 


i" : 


:= -.i" 


i" : 


:= C | AS\ AA 


C : 


:= cond(X) 


AS : 


:=s£ activeS 


AA : 


:= a £ active A 



Where cond(X) is a predicate on the set of SFC variables X. For an SFC, we can stati- 
cally analyze the model and find the activation relation between steps and actions, which 
can help us to express the invariants in SFC models. Let Sjv(a) = {s £ S \ a £ s.Q} 
denote the set of steps associated with an action a. A structural invariant that holds for 
all non-extended SFCs is: 



Y s G activeS A a e active A V I I n(s£ activeS) A ->(a € active A) 

,s£S N (a) I I \\seS N (a) 
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This invariant says if at least one step that can invoke the action a is in active state, 
the action a is also in active state, otherwise a is not active. 

Invariants on BIP Models An invariant in a BIP model can be expressed using the 
following syntax: 





:= i 


i 


:= i A i 


i 


■i 

:= i 


■/ 

i 


:= i' V i' 


i' 


:=i" 


i" 


| •// 


i" 


:= C | L | C f\L 


C 


:= cond(var(s)) 


L 


:= atl(s) = I 



where atl(s) = I is true if the component s is at location I, and cond{var(s)) is a 
predicate on the variables of s. The structure of this invariant language reflects the 
invariant generated by D-Finder |5j. Some examples are given in Section 3.2 



Invariant Transformation From the previous definition, we see that any BIP invariant 
can be written as logical expressions of two basic sets of elements: predicates on variables 
of individual component and predicates on locations of individual components. We 
introduce an invariant transformation function Tj, which takes an BIP invariant / and 
returns the corresponding invariant in the SFC domain. It is defined inductively: 

T;(/ 1 A/ 2 )=T;(/ 1 )AT;(/ 2 ) 

T I (I 1 vf 2 ) = T I (f 1 )VT I (f 2 ) 

As it can be seen, the function Tj keeps the structure of BIP invariants and maps each 
elementary BIP predicate to a corresponding predicate in the SFC domain. Given a 
BIP model B = T{S) transformed from an SFC model S, the mapping of elementary 
predicates on B to predicates on S is described using following rules. The notion s.L 
denotes the set of all locations of BIP atomic s. 

1. For a predicate on variables p = cond(var(s)) we distinguish the following cases: 

• if s is a GV component created for SFC variable x, s has only two variables 
v and t by definition. Since the relationship between v and t is a simple 
assignment, the condition can be written in the form condt(t) A cond v (v). 
Then, the corresponding predicate in SFC domain is T/(p) = cond v (x), i.e. 
we ignore the condition on t and apply the condition on v to SFC variable x; 
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• if s is a ACB component, it contains a boolean variable e. The predicate p 
is a boolean expression on these variables. Let a be the corresponding SFC 
action that s is created for, the transformation of p is done by keeping the 
structure of expression and doing the replacement: Tj(e) = a E activeA; 



• if § is an other component, Tj(p) = true. Actually, this rule is not used, 
since only GV and ACB component contain variables according to the model 
transformation rules. 

2. For predicates on locations we distinguish the following cases: 

• if s is a step component, Tj(atl(s) = DISABLE) = —>(s E activeS) and 
T[(atl(s) = I) = s £ activeS, \/ I E s.L\{DI SABLE}, where s is the step in 
SFC that s is transformed from; 

• if s is a ACB component created for SFC action a, Tj(atl(s) = ENABLE) = 

V s E activeS and Ti(atl(S) = I) = false,Vl E s.L\{EN ABLE}; 

• if s is other component, Tj(p) = false. 

In the invariant transformation procedure, some unused predicates on locations are 
eliminated by setting them to false in the transformed SFC invariant. This is safe because 
the BIP component invariants have a disjunction form as mentioned before. 

Example. For an ACB component s (Figure [7]), an obvious invariant can be found as: 
I = ->(atl(s) = ENABLE) V (atl(s) = ENABLE A e). By applying the transformation 
rules, we can obtain I = (-> \f s E activeS) V (( V s E activeS) A a E activeA), 

which is an invariant contained in the example SFC structural invariant we found before. 

Another set of invariants that can be identified in BIP models are interaction in- 
variants. Let's consider a BIP model transformed from a simple SFC shown in Figure 



17 The transformed BIP model consists of (besides other necessary components) two 
step atomics and one guard atomic. A connector {(53, tOut), (54, tin), (Guard, g)} is 
built by the transformation. The interaction described by the above connector is en- 
abled if atl(S3) = ACTIVE A atl(S4) = DISABLE A atl(Guard) = ACT A Guard.g 
hold. An obvious interaction invariant that can be observed is that one of 53 and 54 
must be in DISABLE location, i.e. atl (53) = DISABLE V atl(S4) = DISABLE 
must hold. By applying the transformation rules, the predicate in SFC domain is 
-■53 E activeS V ->54 E activeS, which obviously holds by the semantics of SFC. 



Proof of G2 The proof of second goal comes strait forwardly from the definitions 
of R and Tj. Consider a configuration c of an SFC model and a configuration c of 
the transformed BIP model, we now show that if R(c, c) holds, then for an arbitrary 
invariant I |= c in the BIP domain, the transformed predicate / = Tj(I) holds for c in 
the SFC domain. Since / and I have the same structure, it is sufficient to show that all 
the elementary predicates in I evaluates to the same value as the transformed predicates 
in /. We make a case distinction on the two types of predicates. The first type are 
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predicates on variables of some component s. We can see from the model transformation 
rules only the GV and ACB component contains internal variables. The rulei and rules 
in the definition of R guarantees that the predicates before and after transformation re- 
evaluate to the same result. The second type are predicates on locations. As stated in 
the definition of Tj, only the predicates on step components and ACB components are 
kept. For the case of step components, the rule\ guarantees the correctness. For the 
case of ACB components, the correctness comes from the structure of the ACB: when 
we move to the ENABLE location, at least one step component has interacted with the 
ACB via the activation port, which means at least one step component must be active 
in the first place. 

6 Transformation of SFC Safety Requirements into BIP 
Invariants 

The BIP framework provides a set of invariant-based formal verification tools. An im- 
portant usage scenario is using these existing tools to verify safety properties on the 
BIP level. Invariants discovered on BIP to show the absence of deadlocks fall into this 
class of properties. However, some safety requirements may already be specified on the 
original SFC models. For that, besides transforming the SFC model into BIP, we also 
need to translate these requirements into BIP domain. 

A safety requirement specifies typically a set of non-safe configurations in the SFC S 
that should be never be reached. Here we provide a solution to ensure the unreachability 
of unsafe configurations. We define a translation function. It has the form Tr : C — > V 
and takes an SFC configuration c 6 C and returns a predicate p 6 V on the transformed 
BIP model B. Since the BIP model specifies more behavior, a translated predicate are 
not necessarily a single BIP configuration but can be a set of configurations. 

This property translation function Tr can be defined as follows: 

Tn((activeS, active A, /)) = 

Vs e activeS . -.(atZ(s) = DISABLE) 
AVa G active A . b a .e = 1 
AVx G X . a(x.v) = f(x) 

After translating the safety requirements, one has to ensure that it does indeed hold 
in the BIP domain. Verifying that such a safety requirement is fulfilled is equivalent to 
showing B |= —>p where p is a predicate specifying the unsafe configuration. This means 
—>p is an invariant of the system. 

The transformation function stated above is safe because the returned invariants in 
the bip domain are at most as strong as the corresponding invariants in the SFC domain, 
as discussed in Section [5j 
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7 Concluding Remarks 



In this report we presented the formalization of the transformation from the SFC lan- 
guage of the IEC 61131-3 standard into bip. Furthermore, we have presented transfor- 
mations for invariants over IEC 61131-3 to invariants over BIP and vice versa. These 
transformations are accompanied by a correctness proof which is based on the semantics 
of the involved language. 

The drawbacks of this work comprises the fact that our proof only deals with ab- 
stract transformation rules. We did not achieve a verified implementation yet. We are 
currently implementing the transformations in Java using the Eclipse Modeling Frame- 
work Regarding correctness guarantees, we are working on a certificate generation 
and checking infrastructure similar to those described in (6j [7J [8] . 
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